A Graphical User Interface (GUI) is part of a software application that interacts with a user via a graphical display. The GUI receives input from the user through different modes of access, such as a mouse and pointer combination, or through a keyboard. A visual output of a GUI is typically displayed on a display device, such as a computer monitor screen, and includes widgets that allow the user to interact with the GUI. Examples of widgets include windows, captions, buttons, labels, menu bars, toolbars, dialog boxes, menus, icons, etc. An example of a GUI visual output is a window (12) having a menu bar (16) as shown in FIG. 1. In this example, there are two menus in the menu bar (16), an Edit menu (18) and a File menu (20), as indicated by appropriate labels. Widgets may also represent software applications that may be executed by the user, such as a Web Browser widget (22), which represents a Web Browser application, or a pointer icon (24), which represents the position of a mouse.
When the user interacts with the GUI by, for example, clicking the mouse while the pointer is positioned above a widget, a message is sent from the mouse to the GUI. The message is a signal transmitted by a computer on which the GUI is executing, and is directed to and accesses the widget. The message may be relayed from the mouse to the GUI by means of a system tool such as an operating system (or other intermediary software application, such as a windowing toolkit) that manages the computer system or graphical display on which the GUI operates. The GUI interprets the message and determines whether to take action based on the position of the pointer when the mouse was clicked. Referring to FIG. 1, if the user clicks on the File menu (20), a message is sent from the mouse to the GUI, accessing the File menu (20) item. The GUI receives the message, interprets the message and determines that the user wants the File menu (20) to be expanded. The GUI then alters the screen image to reflect the expansion of the File menu (20). The altered screen image with the expanded File menu (20) is shown in FIG. 2. In this example, the expanded File menu (20) includes an Open menu item (26) and a Close menu item (28).
In addition to a mouse and pointer combination, other widget access modes include the mnemonic key combinations in order to access widgets. Referring back to FIG. 1, in order to open the File menu (20), instead of using the mouse and pointer, the user may press and hold down the “Alt” key and press the “F” key, which is underlined in the label of the File menu (20). Likewise, other widgets with underlined letters may be accessed similarly. Also, the user may utilize programmable shortcut keys in order to access menu items. For example, as a shortcut to access the Open menu item (26), the user may press the F2 key that is programmed with the shortcut to open the File menu (20). Shortcut keys may involve key sequences, e.g., a “Control” key plus an “L” key may be used to access a widget.
Another access mode is keyboard navigation. A widget that is highlighted (i.e., the widget that receives action from the mouse or keyboard, usually indicated by a dashed border) is said to have the “focus.” The focus changes from one widget to another widget every time a key, e.g., the tab key, an arrow key, etc., is pressed, allowing the user to traverse the widgets by successively pressing the key. When the desired widget has focus, pressing the “Enter” key accesses the widget. Widgets may also be accessed by the accessibility function, which allows one or more software applications that help physically impaired users interact with a GUI or with a computer. For example, in order to allow physically impaired individuals to operate a GUI, customized mechanical devices may be used to detect movements of a user's head by translating movement of the user's head into messages to the operating system and/or windowing toolkit, which relays the messages to the GUI. Thus, a substitute is provided for a mouse. The accessibility function may be implemented and used in a variety of ways, and may assist users to overcome a variety of physical impairments.
As shown in FIG. 3, a GUI testing tool (GTT) (40) is a software application that may be used to perform a test of a GUI (41) in order to detect errors in the construction and operation, etc., of the GUI (41). In order to test the GUI (41), the GTT (40) typically operates in conjunction with a test suite (42). The test suite (42) is a collection of one or more tests or scripts used to determine whether the GUI (41) is functioning as specified. A test typically contains one or more simulated user actions, which are input into the GTT (40), which translates the simulated user actions into messages to be sent to the GUI (41) that is being tested. The simulated user actions are designed to exercise one or more features of the GUI (41) by simulating user actions. For example, the simulated user action “SelectMenu (FileMenu)” simulates a user using the mouse to select the File Menu. The test suite (42) may be created by a person involved in software testing, e.g., a test developer, software engineer, etc.
The test suite (42) is accessed by the GTT (40). The GTT (40) reads a simulated user action (47) (such as the “SelectMenu(FileMenu)”) from the test suite (42) and, based upon the simulated user action (47), generates an input message (48), which is sent to the GUI (41). The input message is directed to the GUI (41) and/or directed to a specific widget or widgets included in the GUI (41). Thus, the GTT (40) simulates user actions directed to the GUI (41). The GUI (41) responds to the input message (48), and the GTT (40) acquires and evaluates the response (49) of the GUI (41) and determines whether the response (49) is proper. In order to determine whether the response (49) is proper, the GTT (40) refers to a reference file (50) that includes a proper response for particular simulated user actions. Alternatively, the reference file (50) may be part of the test suite (42). The GTT (40) compares the reference file (50) contents with the response (49) of the GUI (41) by using a detection tool, such as a widget hierarchy detection tool that obtains a widget hierarchy of the GUI (41) after the GUI (41) has changed in response to the input message (48). The GTT (40) may use other detection tools, such as a bitmap detection tool, in order to determine whether the response (49) is proper. Thus, the GTT (40) may acquire a post-response bitmap drawn by the GUI (41) to use for comparison purposes. Typically, proper responses are gathered prior to testing, stored in the reference file (50), and used later for formal test execution of the GUI (41). Often, the GUI (41) is tested after changes have been made to the software application being tested.
A GUI includes source code statements that handle different tasks. For example, a particular group of source code statements included in the GUI may be responsible for drawing images on a computer screen. Another group of source code statements may be responsible for handling user input from the mouse, and yet another group of source code statements may be responsible for handling user input from shortcut keys. Therefore, different modes of accessing a widget cause different groups of source code statements in the GUI to be executed. Furthermore, different modes of accessing a particular widget cause different messages to be sent to the GUI with which the widget is associated. Typically, a goal of the test developer is to test as many aspects and functions of the GUI as possible, and to cause the execution of as many groups of source code statements included in the GUI as possible. Therefore, a goal of a test developer is to test the widgets in the GUI for different access modes. Generally, the more access modes that are covered during a test of a GUI, the more errors that can be detected. As a result, the final product (i.e., the GUI), as delivered to a customer, is more robust because coverage of access modes during testing is enhanced.